In today's fast paced business environment, software is expected to perform reliably and thus be able to withstand various types of failures. As a result, resiliency testing is often used to verify the quality of software. In resiliency testing, a tester can test the quality of the software by purposely causing failures in the software to see how the software handles or recovers from the failures.
Typically, the software can include multiple software nodes that are each capable of processing incoming application requests. The application request can guide the software application through a set of program states. During resiliency testing, a tester can cause failures to a software node while an application request is being processed to see how the software handles the failure. While cause failures in software nodes can provide feedback on how the software handles failures, the timing in which the software nodes are brought down can greatly affect the results collected. This is due to the fact that the manner in which the software recovers depends on the program state when the software node fails. As a result, the results collected from the testing are inconclusive, which can be frustrating to the tester.